Subject: HPR Control Vector Assignments

From: "jim (j.) cobban" <[email-masked]>
Date: Sat, 27 Jan 1996 10:04:00 -0500

I was told that the issue of control vector identifiers would have to wait
until January, when Ray Bird was available to join the discussion.

I was working on a tool to format out the HPR headers from traces, and I ran
into a small complication.  It appears that HPR has allocated control
vectors using codes which are already in use by other SNA components.  This
does not cause any confusion for the HPR component itself, but it will
complicate writing debugging tools, which do not usually have to worry about
the context in which a particular vector occurs, except where the vector is
explicitly context sensitive.  It must also make the SNA Formats reference a
little confusing.  And, in general, it just looks like sloppy architecture to
have overlaps and duplication of functionality.

Most obvious is that the Node Identifier Control Vector (X'00') (page A-21)
reuses the CVID for the SSCP-LU Session Capabilities CV of the ACTLU RSP as
documented in the SNA Formats reference (GA27-3136-14).

Less obvious, because they are conflicts with the licensed Network Product
Formats reference (LY43-0081) rather than with the public portion of SNA are:

  X'03' Network Identifier CV (page A-22) conflicts with SDLC Secondary
	Station CV
  X'05' Network Address CV (page A-23) conflicts with Channel CV
  X'28' Topic Identifier CV (page A-25) conflicts with Related Session
	Identifier CV

On the other hand the following vectors were slipped into currently unused
or obsolete slots because they are also used in GDS variables or XIDs or
BINDs:

  X'26' NCE Identifier CV (page A-24)
  X'39' NCE Instance CV (page A-26)
  X'61' HPR Capabilities CV (page A-33 Note: not in section A.1.7 with
	others)
  X'62' Session Address CV (page A-38 Note: not in section A.1.7 with others)
  X'67' ANR Path CV (page A-30 Note: out of numerical sequence)

If vectors X'00', X'03', X'05', and X'28' are context sensitive then they
should have been assigned from the range above X'80', as were CVs X'83' (page
A-27) and X'85' (page A-29).  However the first three of these occur in
multiple contexts, although always within an RTP header.

The function of the Node Identifier CV X'00' overlaps with the function of
the existing Network Name CV X'0E'.  Since CV X'00' is used in more than one
place, it should have a common vector identifier.  CV X'0E' with type X'F3'
with the optional network qualifier omitted is the more architecturally
consistent way to carry this information.

The function, and even the format of the HPR Network Id CV X'03' is identical
to the existing Network Id CV X'12' as documented in LY43-0081.

Except for the fact that CV X'05' uses an LT format, that is that the first
byte contains the actual number of bytes in the vector, rather than the number
of words in the vector, CV X'05' looks much more like a segment than like a CV.
It certainly complicated the implementation of my trace tool, and I would
therefore suspect that it complicates the implementation of RTP, that it is
necessary to check for a bit flag earlier in the RTP header to determine
whether CV X'05' is present where, if it was a segment, it would merely be the
first segment.  It is not necessary that the length of this vector ever be
specified as anything other than a number of words because all of the
contained subvectors are aligned on word boundaries.  If this CV was made a
segment the implementation, and the documentation, would be simpler.  As long
as it is known that the receiver understands X'05' as a segment, rather than
as a CV, it is unambiguous to distinguish between both formats.  If CQFI is
set then the CV format is present.  If CQFI is not set then the X'05' segment
may simply be inserted as the first segment, if required.

The existing Related Session Identifier CV X'28' is used by
XRF, which is not currently part of the public specification.  However if we
are actually successful at convincing customers that APPN can replace
existing subarea networks, sooner or later one of them is going to ask about
XRF support in DLUR.  (Dave Mayhew, are you listening?)  At that point the
AIW will have to institute a project to adapt the XRF specification to the
APPN environment, and then the conflict on this CV will become an issue.

CV X'28' appears in only one place, as a subvector of the Connection Setup
segment.  Therefore it should, by the rules, be assigned a context specific
CVID, for example X'80', and documented along with the CS segment.  Note that
the documentation of the CS segment on page A-11 is clumsy.  Firstly it
provides the description of the contents of CV X'28' which is inexplicably
missing from page A-25.  Secondly it treats
CV X'28' differently from the other CVs.  In this the documentation deviates
from the conventions used in the SNA Formats manual.  In other places where a
CV or GDS variable contains several subvectors, and one of them is always
first, the CVIDs are simply listed and the fact that one of them always comes
first and is mandatory is just noted in the list.

MOVED:  That new vector identifiers, which do not conflict with those already
	assigned to SNA CVs be assigned to these vectors.  A bit is added to
	the CV 61 to indicate that the sender understands the new CVIDs.
	If this bit is set in a received XID, and the receiver is capable of
	sending the new values, then the new values are sent to that station.
	All implementations compliant to the current level of the
	architecture will support sending and receiving either the old or the
	new control vector identifiers.

	The following mapping of CVIDs is proposed as a starting point for
	discussion:

	  X'00' is replaced by CV X'0E' with name type X'F3' (LU) with a note
		added that the name is unqualified when carried in an RTP
		segment.
	  X'03' is replaced by existing CV X'12', which is added to the
		SNA Formats with its description copied from LY43-0081.
	  X'05' is replaced by optional segment X'05' of RTP header, that is
		the length field is made a word count instead of a byte
		count.
	  X'28' is replaced by SV X'0D-80' of the Connection Setup Segment,
		and documented with that segment.

	The Common Fields chapter of the SNA Formats document indexes the
	vectors under the non-conflicting identifiers, with a note referring
	to the obsolete context sensitive values.  All control vectors which
	may occur in an HPR/RTP context will have a note referring to the
	alignment rules.

	The new RTP Optional Segments chapter describes the X'05' optional
	segment, with a note that back-level implementations include it in LT
	format and set the CQFI flag.

A note on a related topic.  On page A-32 there is a definition of a
"Composite Route Selection Subfield".  The document does not say what this is
a subfield of, or, indeed, say anything about it.  The fact that it is
identified as X'4685' implies that it is a new subfield of the TG
Descriptor CV X'46'.  There is a reference to this subfield in the discussion
of Border Node, but when this subfield is added to the SNA Formats manual, a
little more explanatory text is desireable.